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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 



1. A request for continued examination under 37 CFR LI 14, including the fee set forth in 37 
CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible 
for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) has been 
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 
1.114. Applicant's submission filed on August 4, 2006 has been entered. 



Claim Rejections - 35 USC § 102 



2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 



3. Claims 1-10, 17, and 19-26 are rejected under 35 U.S.C. 102(b) as being anticipated by Baker 
et al. (USP 6,266,700). 
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4. With regard to claims 1, 20, 21 and 22, Baker et al. discloses a method of communicating 
over a plurality of different target media each having a protocol [the logic control module can 
perform a plurality of functions such as data manipulation, e.g., parsing, filtering, and 
analysis, col. 2, lines 50; logic control module 16 supports the configuration/reconfiguration 
of the programmably configurable protocol descriptions to handle different transmission 
hardware, protocols, and suites (in order to transmit or receive data over that different 
transmission hardware, protocol, or suite), col. 2, lines 59-67], comprising: 

providing, for each of the plurality of different target media, a plurality of communication 
element types hierarchically representing different communication elements for the respective 
protocol, each communication element type being a user-definable data structure that pertains to 
a particular layer of the respective protocol, [the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions which allow changes 
to existing protocols and supports new protocols to be added, col. 2, lines 53-59; any 
possible organization of fields for any possible protocol, col. 7, lines 17-20; defining the 
overall structure of the network protocol and reference other information (e.g., other 
protocols) relative to that network protocol, col. 7, lines 24-27], 
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wherein at least some communication element types relating to higher layers of the 
protocol include references to one or more communication element types relating to lower layers 
of the protocol, and wherein the plurality of communication element types are accessible to at 
least one software program for directing communication over the respective target medium [this 
is inherent in a system (software controlled) that parses frames and breaks them up into 
individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5) (generating multiple 
instances — claim 21); for example, this is interpreted as the system (1) receiving and 
determining the next protocol description structure to be used (table 4, lookup structure 
record, col. 8, lines 35-53) (processing multiple instances — claim 22) (reference to the 
message type — claim 20), then (2) finding the fields that describe the protocol header (table 
1, protocol control record, col. 7, lines 24-46) (reference to the word type — claim 20), and 

then (3) computing the protocol checksum (table 6, checksum record, col. 9, lines 10-20 

i 

(reference to the field type — claim 20); see also this process is described in flowchart 
format: Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 102, then 
PARSEFIELDS 132, then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY 
CHECKSUM 235]. 
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5. With regard to claim 25, Baker et al. discloses communicating over a target medium having a 
protocol [the logic control module can perform a plurality of functions such as data 
manipulation, e.g., parsing, filtering, and analysis, col. 2, lines 50; logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
transmit or receive data over that different transmission hardware, protocol, or suite), col. 
2, lines 59-67], comprising: 

providing a plurality of communication element types for representing different 
communication elements of the protocol each of the plurality of communication element types 
being a user-definable data structure that pertains to a particular layer of the protocol; 
accessing at least one of the plurality of communication element types by a software program, 
and [the user-defined hierarchical data structure is interpreted as the programmably 
configurable protocol descriptions which allow changes to existing protocols and supports 
new protocols to be added, col. 2, lines 53-59; any possible organization of fields for any 
possible protocol, col. 7, lines 17-20; defining the overall structure of the network protocol 
and reference other information (e.g., other protocols) relative to that network protocol, 
col. 7, lines 24-27], 
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directing communications, responsive to accessed communication element types, over the 
target medium using the software program [this is inherent in a system (software controlled) 
that parses frames and breaks them up into individual protocols and fields necessary for 
filtering, gathering statistics, generating network traffic, routing data, verifying field values 
(col. 2, lines 1-5); for example, this is interpreted as the system (1) receiving and 
determining the next protocol description structure to be used (table 4, lookup structure 
record, col. 8, lines 35-53) (reference to the message type), then (2) finding the fields that 
describe the protocol header (table 1, protocol control record, col. 7, lines 24-46) (reference 
to the word type), and then (3) computing the protocol checksum (table 6, checksum 
record, col. 9, lines 10-20 (reference to the field type); see also this process is described in 
flowchart format: Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 102, then 
PARSEFIELDS 132, then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY 
CHECKSUM 235]. 

6. With regard to claim 26, Baker et al. discloses communicating over a target medium having a 
protocol [the logic control module can perform a plurality of functions such as data 
manipulation, e.g., parsing, filtering, and analysis, col. 2, lines 50; logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
transmit or receive data over that different transmission hardware, protocol, or suite), col. 
2, lines 59-67], comprising: 
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providing a plurality of message types and word types for representing communications 
using the protocol, each of the plurality of message types and word types being a user-definable 
data structure; arranging the plurality of message types and word types hierarchically, with at 
least one message type including a reference to at least one word type; accessing at least one of 
the plurality of message types and word types by a software program [the user-defined 
hierarchical data structure is interpreted as the programmably configurable protocol 
descriptions which allow changes to existing protocols and supports new protocols to be 
added, col. 2, lines 53-59; any possible organization of fields for any possible protocol, col. 
7, lines 17-20; defining the overall structure of the network protocol and reference other 
information (e.g., other protocols) relative to that network protocol, col. 7, lines 24-27]; and 
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directing communication, responsive to the accessed message type and/or word type over 
the target medium using the software program [this is inherent in a system (software 
controlled) that parses frames and breaks them up into individual protocols and fields 
necessary for filtering, gathering statistics, generating network traffic, routing data, 
verifying field values (col. 2, lines 1-5); for example, this is interpreted as the system (1) 
receiving and determining the next protocol description structure to be used (table 4, 
lookup structure record, col. 8, lines 35-53) (reference to the message type), then (2) finding 
the fields that describe the protocol header (table 1, protocol control record, col. 7, lines 24- 
46) (reference to the word type), and then (3) computing the protocol checksum (table 6, 
checksum record, col. 9, lines 10-20 (reference to the field type); see also this process is 
described in flowchart format: Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 
102, then PARSEFIELDS 132, then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, 
VERIFY CHECKSUM 235]. 

7. With regard to claim 2, Baker et al. discloses creating, by one of the software programs, 
instances of one or more communication element types for exchanging data on the respective 
target medium [can be configured and reconfigured to implement data manipulation 
functions and accommodate substantial network (bus) modification, col. 2, lines 59-67]. 
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8. With regard to claim 3, Baker et al. discloses wherein the step of providing comprises 
defining one or more of the plurality of communication element types responsive to exchanges 
allowed by the protocol of the respective target medium [it is inherent that the communication 
element types would be defined; see also one or more programmable configurable program 
descriptions, col. 2, lines 50-52], 

9. With regard to claim 4, Baker et al. discloses creating, by one of the software programs, an 
instance of at least one of the plurality of communication element types [the system can 
perform data manipulation, i.e., the logic control module can perform data manipulation, 
e.g., parsing, filtering, and analysis, col. 2, lines 50]; and 

processing each said instance for exchanging information on the respective target 
medium [logic module 16 processes the program description files and extracts field values 
or filtered values, col. 6, lines 15-19]. 

10. With regard to claim 5, Baker et al discloses that at least one of the communication element 
types defines a structure for transmitting data over the target medium [logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
transmit data over that different transmission hardware, protocol, or suite), col. 2, lines 59- 
67], 
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1 1 . With regard to claim 6, Baker et al. discloses that at least one of the communication element 
types defines a structure for receiving data over the target medium [logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
receive data over that different transmission hardware, protocol, or suite), col. 2, lines 59- 
67]. 



12. With regard to claim 7, Baker et al. discloses that at least one communication element type 
is a message type that includes a portion for holding message data associated with instances of 
the respective message type [a data file 20 includes a protocol record organized into a 
plurality of predefined fields, col. 6, lines 64 to col. 7, lines 1; and can be organized to be 
used with any possible protocol, col. 7, lines 17-20]. 

13. With regard to claim 8, Baker et al. discloses that the message data has a fixed length [e.g., 
for example, a particular protocol header length may be fixed, col. 7, lines 3-7]. 



14. With regard to claim 9, Baker et al. discloses that the message data has a variable length [a 
data file 20 includes a protocol record organized into a plurality of predefined fields, col. 6, 
lines 64 to col. 7, lines 1; and can be organized to be used with any possible protocol, col. 7, 
lines 17-20]. 



Application/Control Number: 10/608,588 Page 1 1 

Art Unit: 2616 

15. With regard to claim 10, Baker et al. discloses that at least one of the communication 
element type has a fixed portion that is the same for all instances of the communication element 
type [e.g., for example, a particular protocol header length may be fixed, col. 7, lines 3-7]. 

16. With regard to claims 17, 23, and 24, Baker et al. discloses a method of structuring 
communications over a communication medium having a known protocol, comprising: 

providing a plurality of communication element types for representing communication 
elements at different layers of the protocol, each communication element type having a user- 
definable structure that pertains to a corresponding layer of the protocol [the logic control 
module can perform a plurality of functions such as data manipulation, e.g., parsing, 
filtering, and analysis, col. 2, lines 50; programmably configurable protocol descriptions 
allows changes to existing protocols and supports new protocols to be added, col. 2, lines 
53-59; any possible organization of fields for any possible protocol, col. 7, lines 17-20; 
(inherently, this is a test program — claim 23)].; 

in a software program, creating an instance of at least one of the plurality of 
communication element types [creating a programmably configurable general protocol 
description, col. 5, lines 18-21]; 
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varying at least one characteristic of the instance in the software program and operating 
the software program to direct communications over the communications medium according to 
the instance with the varied characteristic and to determine susceptibility of equipment 
operatively connected to the communication medium to the varied characteristic [this is 
interpreted as determining (testing) dynamic/varying individual field values (e.g., using 
filtering control logic) and generating traffic with the ability to specify the methods for 
varying individual field values, col. 4, lines 44-49; thus, after entering the criteria to be 
tested/filtered, the control logic computes the validity, col. 18, lines 1-25; see also filtering 
criteria can be specified to any subset of bits in any field by allowing the criteria to be 
applied to every instance of that field which appears more than once in a frame, col. 18, 
lines 55-60 (testing varied characteristics of the multiple instances — claim 24)]. 

17. With regard to claim 19, Baker et al. discloses a method of creating an interface with a 
communication medium having a protocol, comprising: 

creating a plurality of user-definable communication element types for representing 
communication elements at different layers of the protocol [the logic control module can 
perform a plurality of functions such as data manipulation, e.g., parsing, filtering, and 
analysis, col. 2, lines 50; the user-defined data structure is interpreted as the 
programmably configurable protocol descriptions which allow changes to existing 
protocols and supports new protocols to be added, col. 2, lines 53-59; any possible 
organization of fields for any possible protocol, col. 7, lines 17-20], 
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saving the plurality of communication element types in a computer readable format 
[written and saved in PDF format, col. 10, lines 51-58]; 

instantiating, via the software program, one or more of the plurality of communication 
element types to create one or more specific instances of communications over the 
communication medium [this is inherent in a system (software controlled) that parses frames 
and breaks them up into individual protocols and fields necessary for filtering, gathering 
statistics, generating network traffic, routing data, verifying field values (col. 2, lines 1-5); 
for example, this is interpreted as the system (1) receiving and determining the next 
protocol description structure to be used (table 4, lookup structure record, col. 8, lines 35- 
53) (reference to the message type), then (2) finding the fields that describe the protocol 
header (table 1, protocol control record, col. 7, lines 24-46) (reference to the word type), 
and then (3) computing the protocol checksum (table 6, checksum record, col. 9, lines 10-20 
(reference to the field type); see also this process is described in flowchart format: Fig. 11, 
PARSEFRAME 100, GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, then 
Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235], and operating 
the software program to run one or more specific instances of communications over the 
communication medium [this is interpreted as generating traffic with the ability to specify 
the methods for varying individual field values, col. 4, lines 44-49; see also specific instances 
of communications using the system: Fig. 11, running PARSEFRAME 100, running 
PARSEFIELDS 130/132, Fig. 12, running PARSEPROTOCOL 150, and Fig. 13A running 
PARSEFIELDS 200]. 
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Claim Rejections - 35 USC § 103 



18. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 



19. Claims 12-16 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Baker 
et al. as applied to claims 1-10, 17, and 19-26 above. 
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20. With regard to claims 12-16 and 18, Baker et al. does not specifically disclose that each 
instance of the message type includes a portion for prescribing timing. However, Baker et al. 
discloses being configured and reconfigured to implement data manipulation functions and 
accommodate substantial network (bus) modification, [col. 2, lines 59-67]. Baker et al. also 
discloses one or more programmable configurable program descriptions, [col. 2, lines 50-52]. 
Baker et al. discloses a system (logic control module), which can perform data manipulation, 
e.g., parsing, filtering, and analysis [coL 2, lines 50] wherein the logic module 16 processes the 
program description files and extracts field values or filtered values [col. 6, lines 15-19]. 
Additionally, Baker et al. discloses a logic control module 16 that supports the 
configuration/reconfiguration of the programmably configurable protocol descriptions to handle 
different transmission hardware, protocols, and suites (in order to transmit/receive data over that 
different transmission hardware, protocol, or suite) [col. 2, lines 59-67]. It is obvious to those of 
ordinary skill in the art that messages/words/packets in several protocols include timing 
characteristics (e.g., leading gaps [claims 13 and 14], trailing gaps [claim 16], and message 
timeouts [claim 15]), which must be specified for correct synchronization and proper extraction 
of headers and payloads. Moreover, Baker et al. discloses data file 20, which includes a protocol 
record organized into a plurality of predefined fields [col. 6, lines 64 to col. 7, lines 1], which 
can be organized to be used with any possible protocol [col. 7, lines 17-20]. Thus, it would have 
been obvious to one of ordinary skill in the art at the time of the invention to have included 
timing characteristics in the programmably configurable message types to handle substantial 
network (bus) modification as well as different transmission hardware, protocols, and suites 
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because such timing characteristics are necessary for working with different types of technology 
and protocols which rely on those timing-based characteristics. 

Response to Arguments 

21. Applicant's arguments filed August 4, 2006 have been fully considered but they are not 
persuasive. 

22. With respect to claim 1, Applicant's representative argues that Baker et al. does not disclose, 
teach, or suggest a communication elements types or a software program [Applicant's 
Amendment of August 4, 2006, page 3, lines 9-13]. The examiner respectfully disagrees. 

23. As stated for rejected claim 1 above, the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions, which allow changes to 
existing protocols and supports new protocols to be added (col. 2, lines 53-59). Baker et al. 
discloses that any possible organization of fields for any possible protocol (col. 7, lines 17-20). 
Moreover, Baker et al. discloses a software controlled system that parses frames and breaks them 
up into individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5) (generating multiple 
instances — claim 21); for example, this is interpreted as the system (1) receiving and determining 
the next protocol description structure to be used (table 4, lookup structure record, col. 8, lines 
35-53) (processing multiple instances — claim 22) (reference to the message type — claim 20), 
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then (2) finding the fields that describe the protocol header (table 1, protocol control record, 
col. 7, lines 24-46) (reference to the word type — claim 20), and then (3) computing the protocol 
checksum (table 6, checksum record, col. 9, lines 10-20) (reference to the field type — claim 
20); {see also this process is described in (software program) flowchart format: Fig. 11, 
PARSEFRAME 100, GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, then 
Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235). Thus, for 
example, the checksum is imbedded in the protocol header, which is imbedded within the 
protocol control record [derived from the received frame]. 

24. With respect to claim 17, Applicant's representative argues that Baker et al. does not 
disclose, teach, or suggest a communication elements types or a software program [Applicant's 
Amendment of August 4, 2006, page 4, lines 23-24, 30-33]. The examiner respectfully 
disagrees. 

25. As stated for rejected claim 17 above, the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions, which allow changes to 
existing protocols and supports new protocols to be added (col. 2, lines 53-59). Baker et al. 
discloses that any possible organization of fields for any possible protocol (col. 7, lines 17-20). 
Moreover, Baker et al. discloses a software controlled system that parses frames and breaks them 
up into individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5) (generating multiple 
instances — claim 21); for example, this is interpreted as the system (1) receiving and determining 
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the next protocol description structure to be used (table 4, lookup structure record, col. 8, lines 
35-53) (processing multiple instances — claim 22) (reference to the message type — claim 20), 
then (2) finding the fields that describe the protocol header (table 1, protocol control record, 
col. 7, lines 24-46) (reference to the word type — claim 20), and then (3) computing the protocol 
checksum (table 6, checksum record, col. 9, lines 10-20) (reference to the field type — claim 
20); (see also this process is described in (software program) flowchart format: Fig. 11, 
PARSEFRAME 100, GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, then 
Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235). Thus, for 
example, the checksum is imbedded in the protocol header, which is imbedded within the 
protocol control record [derived from the received frame], 

26. With respect to amended claim 17, Applicant's representative argues that the amended claim 
limitations (creating and varying a characteristic to determine equipment operation) are not 
disclosed in Baker et al. [Applicant's Amendment of August 4, 2006, page 4, lines 25-26]. 
The examiner respectfully disagrees. 

27. As stated for the rejection of amended claim 17 above, this is interpreted as determining 
(testing) dynamic/varying individual field values (e.g., using filtering control logic) and 
generating traffic with the ability to specify the methods for varying individual field values (col. 
4, lines 44-49). Thus, after the user/operator enters the criteria to be tested/filtered, the control 
logic computes the validity (col. 18, lines 1-25) and therefore, determines equipment operation 
(susceptibility to the filtered criteria). Baker et al. discloses how dynamic/robust this testing is 
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by specifying that the filtering criteria can be applied to any subset of bits in any field in every 
instance of that field which appears more than once in a frame (col. 18, lines 55-60). 

28. With respect to claim 19, Applicant's representative argues that Baker et al. does not 
disclose, teach, or suggest a creating and saving communication elements types or a software 
program [Applicant's Amendment of August 4, 2006, page 5, lines 15-19]. The examiner 
respectfully disagrees. 

29. As stated for rejected claim 19 above, the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions, which allow changes to 
existing protocols and supports new protocols to be added (col. 2, lines 53-59). Baker et al. 
discloses that any possible organization of fields for any possible protocol (col. 7, lines 17-20). 
Moreover, Baker et al. discloses a software controlled system that parses frames and breaks them 
up into individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5), (thus creating and saving); 
for example, this is interpreted as the system (1) receiving and determining the next protocol 
description structure to be used (table 4, lookup structure record, col. 8, lines 35-53) 
(reference to the message type), then (2) finding the fields that describe the protocol header 
(table 1, protocol control record, col. 7, lines 24-46) (reference to the word type), and then (3) 
computing the protocol checksum (table 6, checksum record, col. 9, lines 10-20) (reference to 
the field type); (see also this process is described in (software program) flowchart format: 
Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, 
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then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235). Thus, for 
example, the checksum is imbedded in the protocol header, which is imbedded within the 
protocol control record [derived from the received frame]. 

30. With respect to claim 25, Applicant's representative argues that Baker et al. does not 
disclose, teach, or suggest hierarchical communication elements types or a software program 
[Applicant's Amendment of August 4, 2006, page 5, lines 28-33]. The examiner respectfully 
disagrees. 

31 . As stated for rejected claim 25 above, the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions, which allow changes to 
existing protocols and supports new protocols to be added (col. 2, lines 53-59). Baker et al. 
discloses that any possible organization of fields for any possible protocol (col. 7, lines 17-20). 
Moreover, Baker et al. discloses a software controlled system that parses frames and breaks them 
up into individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5), (thus creating and saving); 
for example, this is interpreted as the system (1) receiving and determining the next protocol 
description structure to be used (table 4, lookup structure record, col. 8, lines 35-53) 
(reference to the message type), then (2) finding the fields that describe the protocol header 
(table 1, protocol control record, col. 7, lines 24-46) (reference to the word type), and then (3) 
computing the protocol checksum (table 6, checksum record, col. 9, lines 10-20) (reference to 
the field type); (see also this process is described in (software program) flowchart format: 
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Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, 
then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235). Thus, for 
example, the checksum is imbedded in the protocol header, which is imbedded within the 
protocol control record [derived from the received frame]. 

32. With respect to claim 26, Applicant's representative argues that Baker et al. does not 
disclose, teach, or suggest hierarchical message and word types or a software program 
[Applicant's Amendment of August 4, 2006, page 6, lines 4-10]. The examiner respectfully 
disagrees. 

33. As stated for rejected claim 26 above, the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions, which allow changes to 
existing protocols and supports new protocols to be added (col. 2, lines 53-59). Baker et al. 
discloses that any possible organization of fields for any possible protocol (col. 7, lines 17-20). 
Moreover, Baker et al. discloses a software controlled system that parses frames and breaks them 
up into individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5), (thus creating and saving); 
for example, this is interpreted as the system (1) receiving and determining the next protocol 
description structure to be used (table 4, lookup structure record, col. 8, lines 35-53) 
(reference to the message type), then (2) finding the fields that describe the protocol header 
(table 1, protocol control record, col. 7, lines 24-46) (reference to the word type), and then (3) 
computing the protocol checksum (table 6, checksum record, col. 9, lines 10-20) (reference to 
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the field type); (see also this process is described in (software program) flowchart format: 
Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, 
then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235). Thus, for 
example, the checksum is imbedded in the protocol header, which is imbedded within the 
protocol control record [derived from the received frame]. 



Conclusion 

34. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure: 

(a) Jones (USP 6,550,235), Universal Communication system. 

(b) Hirata et al. (USP 5,727,149), Network interface apparatus and data transmission 
control method thereof. 

(c) Hebert (USP 5,826,030), Telecommunications switch having a universal API with 
single call processing message including user-definable data and response message each having a 
generic format. 

35. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Mark A. Mais whose telephone number is 572-272-3 138. The examiner 
can normally be reached on M-Th 5am-4pm. 
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36. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Seema Rao can be reached on 571-272-3174. The fax phone number for the organization where 
this application or proceeding is assigned is 571-273-8300. 

37. Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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